UML:統一塑模語言/行為圖形組神掌

在資訊系統愈來愈往大規模化，複雜化的發展趨勢下，促成了統一塑模語言（UML, Unified Modeling Language）的誕生。「塑模」的意思就是以圖形的方式，先將系統的功能與結構畫成「模型」與藍圖，然後再依據藍圖進行實體開發。

UML 2.x 定義的的塑模圖形(UML 2.x Diagrams)下分2大類組：結構圖形組（Structure diagrams）、行為圖形組（Behavior diagrams）。

統雄老師建議：將 2 圖組，再分為A, B 兩組：

A 組：基本圖，適用所有中小型系統分析與設計。亦即，並非所有的圖都要用到。

B 組：進階圖，針對大型系統分析與設計，再使用。

行為圖形組（Behavior diagrams）

類同傳統系統分析中的「前端分析」，強調系統模型中觸發的事件或相關行動，包括：使用個案圖 (Use Case diagram)、活動圖(Activity diagram) 、狀態機圖 (State Machine diagram) 和互動圖形子集合（Interaction diagrams），在子集合內又包括4種圖。

其中最重要的就是使用個案圖 (Use Case diagram)和活動圖(Activity diagram) ，前者是UML 特別定義的概念模型設計，後者就相當於傳統作業結構流程圖(Workflow Chart, WFC)，對一般中小型系統的前端分析，已足以因應。

A 組：基本圖

使用個案圖 (Use Case diagram)

使用個案圖 (Use Case diagram) 在分類上屬於行為圖形組（Behavior diagrams） ，但 UML 認為它也定義了結構圖形組（Structure diagrams）的基礎，所以是跨行為與結構的最重要圖形。

使用個案圖以人形、橢圓、與連結線為主：人形表現使用者 actors，actors 可譯為「行為人」，本系列講義為維持概念一致性，仍稱為使用者。

橢圓就是 use case，由於是專有名詞，直譯「使用個案」，在中文上未盡達意。其英文的白話為 behaviored classifier，直譯為「特定行為類別」，而其意譯即表示：為一種行為概念，而可視為「類別」，即未來可予定義「特性 property」、與「方法 method」。

人形與橢圓中間的直線，稱為連結 association。

這個圖，就是表現「需求分析」的：誰？作什麼？

使用個案圖 (Use Case diagram) 必須與「需求分析」環環相扣

「需求分析」中的「誰？作什麼？」，必須全部出現在「使用個案圖 (Use Case diagram) 的人形、與橢圓中。

「使用個案圖 (Use Case diagram) 的人形、與橢圓，不應該出現「需求分析」中沒有的「誰？作什麼？」。

使用個案圖 (Use Case diagram) 必須與未來的「活動圖(Activity diagram) 」環環相扣

使用個案圖 (Use Case diagram) 為概念模型。

未來的「活動圖(Activity diagram) 」為實體模型，亦即將概念發展為可操作的作業，兩者必須環環相扣。

使用個案圖 (Use Case diagram)再分為「系統」圖與「商業模式」圖２組。

使用個案圖 (Use Case diagram) 再分為2組：一般使用個案圖 (Use Case diagram) 、或稱系統使用個案圖 (System Use Case diagram) ，以及商業模式使用個案圖 (Business Use Case diagram) 。當沒有特別強調系統或商業模式時，就是指一般使用個案圖。

基於傳統教學習慣，本講義先介述一般/系統使用個案圖，但在實務上，如果是新創事業、新創產品，則應先建商業模式使用個案圖。

一般/系統使用個案圖  Use Case diagram / System Use Case diagram

一般/系統使用個案圖相當於「需求分析書」的視覺化，定義使用者類別，與其在系統上的行為，通常會表現互動行為的雙方。

在傳統作業結構流程圖(Workflow Chart, WFC)中，第一個圖示通常是「使用者身分」與其可從事行為選項，而在UML中，就是描述使用者與其行為的 Use Case 圖。

如以下餐廳系統的行為簡化圖。

矩形為 UML 元素圖框 elements frame，在此稱為 subject。框內左上方為 subject 名稱，此為餐廳。

框外左側人形，為需求使用者：人形下方為名稱-顧客；行為：點餐、點飲料、付帳。

框外右側人形，為供給使用者：人形下方為名稱-廚師；行為：烹飪。

在當前以瀏覽器為平臺的系統，圖上所有的橢圓 use case，系統或子系統通常都會以【導覽列】或下拉選單呈現，而模組有可能以個別物件呈現。

自訂圖示

UML 允許自訂視覺輔助圖示，如以下的線上圖書館查詢系統。名稱上方可以«»加注，此為整個圖書館系統的一個模組。

需求使用者：讀者；行為：帳戶管理、搜尋、預訂、重設、意見反映。

供給使用者：相應提供需求的不是個人，而為 1 個組織「圖書館」，並以自訂圖示表現。

系統分割與模組化

為了系統展示的簡明，以及未來分工與再整合的便利，複雜行為的使用個案，可以將整體系統再拆成幾個子系統、與再下層的行為模組，各別作使用個案圖。

如以下線上消費圖，為「線上行銷系統」之子系統«Subsystem»。

前例「餐廳系統」，點餐與買單，都是一次性、非反復的單純行為；但在線上消費時，瀏覽商品與結帳行為，可能一再反復或改變，故另分為 2 個延伸行為圖模組。

客戶分為已登錄的會員客戶，與新客戶，以「總和與隸屬關係」圖示表現。

呼叫 «include» ‧觸發«extend» ‧依存關聯(Dependency)圖示

會員客戶「登入後」（登入行為，另以延伸行為模組呈現）可瀏覽商品、或購買。如果進行購買行為，會再依據依存關聯(Dependency)圖示，「呼叫」 «include» 瀏覽商品與結帳行為。 «include» 所指向的行為，都是出發行為的子集合。注意：結帳行為沒有和客戶連結，亦即，如果客戶必須先進行購買行為，才會產生«include»結帳行為。

而新客戶可以選擇瀏覽商品、或登錄為會員。

瀏覽商品、結帳行為登錄為會員，所需要的驗證 Authentication 與帳戶管理 Identity，前者可以是個服務機制 «Service»，後者就是會員名單管理，兩者均可視為機器人。

結帳行為的支付者，包括：信用卡與 PayPal。

瀏覽商品延伸行為圖模組

瀏覽商品延伸行為圖模組，可以經由客戶進行：搜尋、展示結果、瀏覽推播產品、加入購物車、提供期待產品清單行為，而被「觸發」«extend» 產生瀏覽商品。

在瀏覽推播產品、提供期待產品清單時，會「呼叫」 «include» 客戶驗證。

客戶驗證後，可「觸發」«extend» 加入購物車。

結帳行為延伸行為圖模組

結帳行為延伸行為圖模組，結帳行為會「觸發」«extend»：客戶驗證、確認購物清單、計算費用與運送方式、付款。

其他相應細節，請讀者嘗試解讀。

其中單一登入Single Sign-on，因為本圖僅為「線上行銷系統」之子系統«Subsystem»之一，可能還存在其他：抽獎子系統、事件行銷子系統…等，僅需在1個子系統登入，就可以遊走各子系統。或者也可以由其他使用 Open ID 的系統或網站登入。

「作什麼？」為關聯物件

前例「餐廳系統」，「作什麼？」之點餐與點飲料，但是「實體 entity」物件，亦即菜單與飲料單，都由相關使用者已輸入。

但如「倉庫管理系統」，「誰」為庫管人員，「作什麼」為檢查「庫存記錄」，則其行為係「關聯 relationship」物件，因為並無、也不應由人輸入記錄，而是由「進貨記錄 - 出貨記錄」而得。

如果需求分析之調查正確，且「進貨記錄」、「 出貨記錄」同樣由庫管人員處理，則其「作什麼」應該包括３項，且由「進貨記錄」、「 出貨記錄」«extend»到「庫存記錄」。

如果需求分析之調查「進貨記錄」、「 出貨記錄」是由其他部門：採購部、生產部所記錄，則「誰」應該包括另２個使用者，且在圖上表現出互動。

商業模式使用個案圖 Business Use Case diagram

商業模式使用個案圖 Business Use Case diagram 係基於統一軟體開發過程 Rational Unified Process, RUP，創造了整體解決方案架構時代的變革。

UML:統一塑模語言 

行為圖形組（Behavior diagrams）1：使用個案圖  Use Case diagram

行為圖形組（Behavior diagrams）2：活動圖 Activity diagram 與進階圖

結構圖形組（Structure diagrams）

UML Diagrams Org的詳細資料